Skip to content

Conversation

Havvy
Copy link
Contributor

@Havvy Havvy commented May 21, 2018

No description provided.

@Havvy Havvy requested review from matthewjasper and alercah May 21, 2018 03:27
Copy link
Contributor

@matthewjasper matthewjasper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@@ -53,7 +53,7 @@ sites are:
}
```

* Function results, either the final line of a block if it is not
* Function results – either the final line of a block if it is not
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style nitpick: shouldn't this be an em dash without surrounding spaces?

@@ -91,7 +91,7 @@ the block has a known type.

Coercion is allowed between the following types:

* `T` to `U` if `T` is a subtype of `U` (*reflexive case*)
* `T` to `U` if `T` is a [subtype] of `U` (*reflexive case*)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the "reflexive case" annotation mean anything here? T to U when they are distinct is not reflexivity, although this does imply reflexivity because T is a subtype of T

@@ -164,8 +164,7 @@ the compiler will provide an implementation of `Unsize<U>` for `T`:

* `[T; n]` to `[T]`.

* `T` to `U`, when `U` is a trait object type and either `T` implements `U` or
`T` is a trait object for a subtrait of `U`.
* `T` to `dyn U`, when `T` implements `U + Sized`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think + Sized is accurate here; without it, coercions of references won't always work because going from &T to &U would require that T be sized. Unless that's actually how it works?

@alercah
Copy link
Contributor

alercah commented Aug 3, 2018

@Havvy Can you make the changes for this one?

@@ -1,10 +1,10 @@
# Type coercions

Coercions are defined in [RFC 401]. [RFC 1558] then expanded on that.
A coercion is implicit and has no syntax.
**Type coercions** are implicit changes of the type of a value. They happen
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: An implicit coercion is essentially an implicit operation on a value. The value doesn't so much change type as there's an invisible "function call" on the value that produces a different value (this gets muddied a bit by subtyping and ownership). The language Idris allows one to define implicit functions and one can think of the implicit coercions in Rust as a set of those.

@Havvy
Copy link
Contributor Author

Havvy commented Nov 5, 2020

This is outdated.

@Havvy Havvy closed this Nov 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants